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(54) IEEE 1394 Serial bus system using a map|4ng table for identifying nodes having required 
capabilities to estabfish isochroiious connections 

(57) In an IEEE-1394 serial bus system, a control- 
ling node reads information from the configuration ROM 
of each of other nodes attached to the bus and estab- 
lishes in a mapping table a correspondence between 
the Identifier of each node and the read information. The 
controlling node identifies particular nodes having 
required capabilities according to the information stored 
in the mapF^ng table and requests an isochronous 
resource manager to obtain information necessary for 
transmission of isochronous data. The obt^ned infor- 
mation is then set into plug control registers of the Iden- 
tified nodes to establish a connection between the 
identified nodes. 
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Description 

BACKGROUND O F THE INVENTION 

Held of the Invention 5 

[0001 1 The present invention relates generally to IEEE 
1394 serial bus systems and more specif ically to an 
IEEE 1394 node capable of establishing connections for 
isochronous transmte^ons. 

Descrirrtion of the Related Art 

[00021 The EEE-1394 Standard for a High Pertorm- 
ance Serial Bus spedftes a sequence of different proc- is 
esses to be performed when the bus is initialtzed. One 
of such processes Is the self identification process in 
which all nodes attached to the bus are Informed of the 
node identifiers of all ottier nodes and the maximum 
speed of each bus segment that is attached between so 
two nodes. However, if it is desired to transfer Iso- 
chronous data such as video programs between two 
nodes of particular vendors, details of node infonriation 
such as node capabilities and their node type are still 
required in order to identify the nodes supporting iso- 25 
chronous transmission before establishing a connec- 
tion. 

SUMMARY OF THE INVENTION 

30 

[0003] It is therefore an object of the present invention 
to identify nodes having required node capabilities for 
isochronous transmission and establish a connection 
between the Identified nodes. 

[0004] According to the present invention, there is pro- 35 
vided an IEEE-1394 serial bus system in which a plural- 
ity of nodes are attached to the serial bus. each of the 
nodes including a configuration ROM and Identified by a 
node kfentifier. At least one of the nodes comprises a 
mapping table and control drcu'rtry for reading infonna- 40 
tion from the configuration ROM of each of other nodes 
and mapping tiie identiTier off each other node to the 
read information in the mapping tat)le, identifying a 
node having required node capabiltties according to 
information scored in tfie mapping table, requesting an 45 
isochronous resource manager to obtain inforrr^tion 
necessary for transmission of isochronous data, and 
setting the obtained information into the identified node 
to establish a connection which supports said transmte- 
sion. 

BRIgP DESCRIPTION OF THE DRAWINGS 

[0005] The present invention will be described in fur- 
ther detail with reference to the accompanying draw- ss 

ings, in which: 

Rg. 1 shows in block diagram form an IEEE 1394 



serial bus tree topology network according to tiie 
present invention; 

Rg. 2 shows details of a configuration ROM of eadi 

node of the tree topology network; 

Rg. 3 shows a table mapping process of the 

present invention at the level of transaction layer; 

Rgs. 4A to 4D show in flow diagram fomn the tat>le 

mapping process of a controlling node; 

Rgs. 5A to 5D show the formats of packets used in 

the present invention; 

Rg. 6 ^ows in flow diagram form the operation of 
tiie connection establishment process of the con- 
trolling node; 

Rg. 7 shows Information set in plug control regs- 
ters of audioMsual nodes; and 
Rg. 8 shows one sample of connections estab- 
lished among aucSo/veual nodes of the IEEE 1394 
tree topology network. 

DETAILED DESCRIPTION 

[0006] Refening now to Rg. 1 , there is shown an IEEE 
1394 serial bus tree-topology network according to tiie 
present invention. The network is comprised of a plural- 
ity of IEEE 1394 devices, or nodes. One of the nodes is 
a oontrolting node 1 and tiie other nodes are controlled 
nodes, or target nodes 2A to 2Q attached to ttie control- 
ling node by local buses 3 and 4 in a tree-like topology. 
Nodes 1 and 2 may be audio/visual devices or personal 
computers, or computer peripheral devices, all of which 
are designed to the IEEE Standard for a High Perfomn- 
ance Serial Bus (or IEEE Std 1394-1995) which sup- 
ports both asynchronous and isochronous 
transmissions, simultaneously. 
[0007] Controlling node 1 includes a controller 10, a 
transaction layer processor 1 1 , a link layer processor 12 
and a physical layer processor 13, all of which are con- 
nected to a bus manager 14. By way of the processors 
11 to 13, tiie controller 10 transmits and receives sig- 
nals to and from the local buses 3 and 4. Further asso- 
ciated witii the controller 10 is a mapping table 15 in 
which the controller 1 0 maps node identifiers to the cor- 
responding device information items obtained from tiie 
configuration ROM of target nodes in a manner as will 
be described in detail later. 

[0008] A memory 16 is provided within the bus man- 
ager 14 and a configuration ROM 17 Is defined within 
the memory 16. Each of target nodes 2A to 2G has its 
own configuration F^M. 

[0009] As shown in detail in Fig. 2, tiie memory 16 of 
tiie controlling node as well as target nodes 2A to 2G is 
partitioned into a plurality of register spaces including 
the space for tiie configuration ROM 17, a space for 
GSR (control and status register) 18, and initial units 
space 19. Bus manager 14 controls the layers 11. 12 
and 13 according to tiie contents of tiie CSR memory 
space 18. After the mapping table 15 is completed, the 
controller 10 exchanges command messages witii other 
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nodes using addresses specified In the CSR memory 
^ce 18. 

[001 01 Conf Wfuration ROM 1 7 is divided into a number 
of storage locations each with a 32-bit (c^adlet) wide 
memory space. These quadlet storage locations are 
grouped Into sections such as busJnfo_b!od<. 
root_directory, unitjdirectories and a 
node_unique_id Jeaves. and each section begins with a 
memory space in whi^ the data length of the section 
and error check data are Indicated. 
[0011] Audio/visual nodes are provided with master 
plug registers arKJ plug control registers designed to the 
lEC standard 61883 for digital interface for consumer 
electronic audla/^ideo equipment (reference number 
100C/46 ~ 50/CVD. project number 100C/61883- 
1~5/Ed.1). A maximum of thirty-two plug control regis- 
ters are provided in each of the target nodes 2. In each 
of these plug control registers are stored information 
relating to the presence/absence of broadcast connec- 
tion, the number of point-to-point connections, the iden- 
tification of an isochronous channel and the transfer rate 
and bandwidth of the isochronous channel. Manage- 
ment of the plug control registers is provided by the 
master plug registers. Plug control registers and master 
plug registers is defined within the initial units space 19 
as illustrated in Fig. 2. 

[0012] Controlling node 1 begins its operation with a 
bus initialization process by asserting a bus reset on 
local buses 3 and 4. Following the bus initialization, a 
tree identification process begins to identify the root 
node and the isochronous resource manager and the 
topology of all attached nodes, resulting in all ports of 
the nodes being designated as eitiier child or parent 
ports. A child port connects to a node further away from 
the root while a parent port connects to a node closer 
to the root. The tree identificalion process is then fol- 
lowed by a self identification process during which a 
physical identification is assigned to each node, neigh- 
boring nodes exchange their speed capabilities and the 
topology defined during tree identification. 
[0013] Fbllowing the self identification process, ttie 
controller 10 performs a mapping process on the table 
15. The cable mapping process of contioller 10 begins 
at tfie transaction layer with a target node, 2 A, for exam- 
ple, to establish con-espondenc^ In the mapping table 
15 between the identifier of the node 2A and a number 
of its unique device tnfomnation items. As illustrated, tiie 
controller 1 0 at node 1 sends a transaction request to its 
transaction layer 1 1 to forward a read request packet to 
the transaction layer 1 1 A of node 2 A. which replies with 
an acknowledgment packet and sends a ti-ansaction 
indication to its configuration ROM 1 7A. This results in a 
desired data item being read out of the configuration 
ROM 1 7A and traremitted as a transaction response to 
the transaction layer 11 A. The configuration ROM data 
is placed in the data field of a read response packet and 
sent from the transaction layer 11A to the transaction 
layer 11. which returns an acknowledgment packet to 



node 2A and sends a transaction indication to the con- 
troller 10. The oonfigurafion ROM date of node 2 A con- 
tained in the transaction indication is mapped in tite 
mapping table 15 to the Identifier of node 2A. 

5 [0014] The following is a detailed description of tiie 
table mapping operation of controller 10 with the aide of 
tiie flowcharts of Rgs. 4A to 4D by uang the standard- 
ized packets as shown in Rgs. 5A to 5D. 
0)015] The table mapping process begins witii tine 

10 reading of busjnto.block section data from all target 
nodes. At step 1 01 . the controller 1 0 formulates a Read 
Data Quadlet (RDQ) unicast request pad^et (Rg. 5 A) by 
setting SFF^e (=1023) in tiie ten most significant bits of 
the destination ID field to spedfy all local buses and set- 

15 ting one of 0^ e ^^16 ^ ^® ^^^^^ signif icant bits and 
an address (FFFFF0000400i6) in the destination joffset 
field indicating the first quadlet data of busJnfo_bIod< 
section. In this way, RDQ unicast packets can be indi- 
vidually addressed to a maximum of sixty-three target 

20 nodes. 

[0016] All nodes recognizing a receipt of the RDQ 
request packet know that they are being targeted and 
respond with a RDQ response packet which is shown in 
Fig. 5B. More specifically, each target node reads the 

25 first quadlet (four bytes) data of busjnfo_block section 
of its configuration ROM as specified by tiie 
destination^offset field of the received packet and 
inserts tiiis first quadlet data into the quadlet_data field 
of tiie RDQ response packet as well as the node ID of 

30 ttie target node into Its source_ID field. This first quadlet 
data includes the data lengtii of the busjnfb.block sec- 
tion and ORG information (see Rg. 2). 
[0017] In response to receipt of tiie RDQ response 
packet from each target node (step 103). tiie controller 

35 10 proceeds to step 104 to save the source address 
contained in its source_ID field and reads the length 
data of busjnfo.block section from the quadlet data 
field. 

[001 8] At step 1 05. tiie controller 1 0 checks to see if 
40 RDQ response packets are received from all target 
nodes. If not, flow returns to step 1 01 to repeat the proc- 
ess until RDQ response packets are received from all 
target nodes. 

[001 9] When the decision at step 1 05 becomes aff imi- 
45 ative, flow proceeds to step 106 to add one quadlet to 
the Initial offset data to produce a summed address 
value FFFFF0000404i6 which indicates tiie second 
address location of tiie busjnto.block section and sub- 
tract one quadlet from the lengtii data saved at step 
so 104. 

[0020] At Step 107. the controller 10 formulates a uni- 
cast Read Data Block (RDB) request packet (see Rg. 
50) for a target node by setting tiie saved identifier of 
tiie node in tiie destination ID field of the packet tiie 
55 summed address value in the destination.offset field 
and the subtracted length data in the datajength field, 
tiie packet bang fonnarded onto all local buses (step 
108) so that only one node specified by the destination 
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ID field knows that it is being targeted. 
[0021 ] In response to the RDB request packet, the tar- 
get node replies with a RDB response packet (Rg. 5D) 
by setting its data field with busjnfo.block section data 
that becpns with the second address location specified 
by the request packet. 

[0022] Upon receipt of the RDB response packet from 
a target node (step 109). the oontroller 10 proceeds to 
step 110 to estedsfish a correspondence in the mapping 
table 15 between the target node identifier and the 
busjnfo.block section data contained in the response 
packet 

[0023] At step 1 1 1 , the controller 1 0 chec^ to see if 
RDB response packets are received from all target 
nodes. If not. flow returns to step 1 06 to repeat the proc- 
ess until RDB response packets are received from an 
target nodes. 

[0024] Following the affirmative decision at step 111. 
fkw proceeds to step 201 (Fig. 4B) to start reading 
root_directory section data from the target nodes in a 
manner similar to the routine of Fig. 4A by formulating a 
unicast RDQ request packet. In this unicast request 
packet all-bus address SFF^e is set in the ten nrtost sig- 
nificant bits of the destination ID field and an individual 
askiress is set in the six least significant bits similar to 
step 101 and tiie first address (FFFFF000041 4^6) of the 
root__directory section is set in the destination_offset 
field. 

[0025] The RDQ request packet is fonivarded to all 
local buses (step 202) so that all nodes know that they 
are being targeted and reply with RDQ response pack- 
ets each containing the data length of the rootjdBrectory 
section in its quadlet data f i^d. 
[0026] Upon receipt of the RDQ response packet from 
each target node (step 203). the controller 10 proceeds 
to step 204 to save the source identifier and the length 
data of the root.directory section. 
[0027] At step 205. the controller 10 checks to see if 
RDQ response packets are rec^ved from all target 
nodes. If not, the flow returns to step 201 to repeat the 
process until RDQ response packets are received from 
an target nodes. 

[0028] When the decisicxi at step 205 becomes affirm- 
ative, flow proceeds to step 206 to add one quadlet to 
the initial offset data to produce a summed address Indi- 
cating the second address location of the rooLdirectory 
section and subtract one quadlet from the length data 
saved at step 204. 

[0029] At step 207. the controller 10 fonrmlates a uni- 
cast RDB request packet for a target node by setting the 
saved identifier of the node in the destination ID field of 
the packet the summed address value in the 
destination, offset f iekJ and the siiblrsK:ted length data 
in the datajength field. The packet is fbravarded onto all 
local buses (step 208) so that only one node specified 
by the destination ID field knows that it is being tar- 
geted. 

[0030] In response to the RDB request pad^t the tar- 



get node replies with a RDB response packet containing 
in its data field rootjdirectory sectbn data that begins 
with the secOTd ^ress location specified by ttie 
request packet 

5 [0031] Upon recent of the RDB response packet from 
a target node (step 209). the controller 10 proceeds to 
step 210 to estat^ish a corespondence in the mapping 
table 15 between the idafttifier of the target node and 
the rootjdirectory section data contained in the 

10 response packet 

[0032] At step 211. the controller saves the 
unit_directory offset data and node_uniqueJdJeaf off- 
set data contained In the data field of the response 
packet, and proceeds to step 212to check to see If RDB 

15 response packets are received from aD target nodes. If 
not. fkTw returns to step 206 to repeat the process until 
RDB response packets are received fifom all target 
nodes. 

[0033] Following the affirnDative decision at step 212. 

so flow proceeds to step 301 (Fig. 4C) to start reading the 
unitjdirectory section data from each target node by for- 
mulating a unicast RDQ request packet In this unicast 
request packet the identifier of a node saved at step 211 
is set in the destination ID field and the unitjdirectory 

25 offset data saved at step 211 is set In the 
destination_offset field. The unicast packet is fbnuarded 
onto the local buses at step 302. so that only one node 
knows that It is being targeted. The target node replies 
with a RDQ response packet containing the length data 

30 of the unit_directory section. 

[0034] When the controlling node 1 receives the RDQ 
response packet (step 303). flow proceeds to step 304 
to save the node identifier and length data and pro- 
ceeds to step 305 to check to see if RDQ response 

35 packets are received from all target nodes, if not. flow 
retums to step 301 to repeat the process until RDQ 
response packets are received from aU target nodes. 
[0035] When the decision at step 305 becomes affirm- 
ative, flow proceeds to step 306 to add one quadlet to 

40 tiie unitjdirectory offset data of a given node saved at 
step 304 to specify the second address bcation of 
uratjdirectory section and subtract one quadlet from the 
length data saved at step 21 1. 
[0036] At step 307. the oontroller 10 fbrnulates a RDB 

45 request packet for the given node by setfing its saved 
identifier in the destination ID field, summed address in 
the destination^offset fiekf and tiie subtracted lengtii 
data in the datajengtii field. At step 308. the RDB 
request packet is fonManied onto the local txises. 

50 [0037] In response to the RDB request packet, tiie 
given target node replies with a RDB response packet 
containing in its data field unitjdirectory section data. 
[0038] When the oontroller 10 receives ttie RDB 
response pad^ at step 309, it proceeds to step 310 to 

55 establish a correspondence in the mapping table 15 
between the identifier of the given node and the 
unitjdirectory section data contained In the packet. At 
step 311. the controller 10 checks to see if RDB 
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re^onse pad^ets are received from ail target nodes. If 
not steps 306 to 310 are repeated until RDB re^nse 
packets are received from all nodes. 
[0039] Following the affirmative decision at step 31 1 . 
flow proceeds to step 401 (Rg. 4D) to start reading 5 
node_unique_ idjeaf section data from each target 
nodel>y formulating a unica^ RDQ ro^uest packet In 
this unicast request packet the identifier of a node saved 
at step 211 is set in the destination ID field and the 
node_uniquejdJeaf offset data saved at step 211 is io 
set in the destination_offset field. The unicasl packet is 
fonwarded onto the local buses at step 402. so that only 
one node knows that it is being targeted. The target 
node replies with a RDQ response pad^t containing 
the length data of the node_uniqueJdJeaf section. is 
[00401 In response to receipt of the RDQ response 
packet (step 403). flow proceeds to step 404 to save the 
node identifier and length data and proceeds to step 
405 to check to see H RDQ response packets are 
received from ail target nodes. If not, flow returns to step 20 
401 to repeat the process until RDQ response packets 
are received from all target nodes, 
[0041 ] When the decision at step 405 becomes affirm- 
ative, flow proceeds to step 406 to acid one quadlet to 
the node_uniqu8jdJeaf offset data of a givai node 25 
saved at step 404 to specify the second address loca* 
tion of node_uniqueJdJeaf section and subtract one 
quadlet from the length data saved at step 21 1 , 
[0042] At step 407, the controller 1 0 formulates a RDB 
request packet for the given node by setting its saved so 
identifier in the destination ID field, summed address in 
the destination_offset field and the subtracted length 
data in the datajength field. At step 408. the RDB 
request packet is fonwarded onto the loca! buses. 
[0043] In response to the RDB request packet the 35 
given target node replies with a RDB response packet 
containing in Its data field nodejLinique_idJeaf section 
data. 

[0044] When the controller 10 receives the RDB 
response packet at step 409, it proceeds to step 410 to 40 
establish a correspondence in the mapping tat^e 15 
between the identifier of the given node and the 
unitjdirectory section data contained in the packet. At 
step 411. the controller 10 checks to see if RDB 
response packets are received from all target nodes. If 45 
not steps 406 to 410 are repeated until RDB response 
packets are received from all nodes, whereupon all rou- 
tines of ttie table mapping process is tenminated. 
[0045] With the mapping table 1 5 being completed as 
shown in Fig. 1 . the controlling node 1 starts a process so 
for establishing a connection between two audio/visual 
nodes. 

[0046] As shown in Fig. 6. the connection establish- 
ment process begins with step 61 in which the controller 
10 reads information from all entries of the mapping ss 
table 15 and identifies nodes having isochronous trans- 
mission capabilities. At step 62. the controller 10 sends 
an asynchronous lock packet to the isochronous 



resource manager to requ^ the use of a t>ancfcyklth. If 
the requ^ is granted, the isochronous resource man- 
ager returns a response packet indicating a channel 
number arKJ a bandviridth. The controller 10 sets the 
requested information and other necessary information 
into the input and output plug control regist^ of the 
identified nodes as shown in Fig. 7 according to the 
IEC-61883 standard. At step 63. the controller 10 com- 
mands the output plug control register to establish a 
connection to the input plug control register according to 
the set information. In this way, an isochronous channel 
is established between audioAnsual nodes for transmis- 
Bon of isochronous data. 

[0047] Rg. 8 shows one example of connections 
established among audio/visual nodes of the present 
invention. It Is seen that a plurality of connections are 
established on a single isochronous channel. One 
point-to-point connection 81 is established between the 
output plug control register 91 of node 71 and the Input 
plug control register 95 of node 75. two point-to-point 
connecttons 82 are estat)Ii^ed between tiie output 
PGR 91 and the input PGR 93 of node 73. and three 
point-to-point connections 83 are established between 
the output PGR 91 and tiie input PGR 92 of node 72. 
Additionally, a broadcast-out connection 84 is estab- 
lished between the output PGR 91 and tiie broadcast 
channel number of the isochronous channel and a 
broadcast-in connection 85 is established between the 
input PGR 95 and tiie broadcast channel number. 
These broadcast connections are estatdished inde- 
pendentiy of the operating states of tiie transmit and 
receive nodes. The plug control registers of tiie broad- 
cast connections can be rewritten from any other nodes 
of ttie network, so ttiat an established broadcast con- 
nection can be cleared and the ownership of tiie con- 
nection be transferred to another node. 
[0048] With a connection being established between 
two audioAnsual nodes, start/^top. pause and slow- 
motion commands (AV/G commands) are used to con- 
trol video program transmissions according to ttie func- 
tion control protocol (FCP) of the IEG-61883 standard 
(step 64). At the end of the isochronous transmission 
(step 65). the input and output plug control registers of 
the audio/visual nodes are reset to release tiie connec- 
tion (step 66). 

Claims 

1. A node attached to an IEEE-1394 serial bus for 
controlling devrces attached to said bus. each of 
said devices including a configuration ROM and 
identified by an identifier, said node comprising: 

a mapping cable: and 

control circuitry for reading information from tiie 
configuration ROM of each of said devices and 
mapping the identifier of ttie device to tiie read 
information in said mapping table, identifying a 
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device having required capabilities according 
to information stored in said mappng t^e. 
requesting an isodironous resource manager 
to obtain information necessary tor transmis- 
sion of isochronous data. arKi setting the 
obtained infomration into said kJentified device 
to establish a connection which supports said 
transmission. 

An IEEE-1394 serial bus system in whidi a plurality 
of nodes are attached to tiie serial bus. each of said 
nodes including a configuration ROM and identified 
by a node identifier, at least one of said nodes com- 
prl^ng: 

a mapping table; and 

control circuitry for reading information from the 
configuration ROM of eadh of otiier nodes and 
mapping the Identifier of each otiier node to the 
read Information in said mapping table, identi- 
fying a node having required node capabilities 
accorcfing to information stored in said map- 
ping table, requesting an isochronoie resource 
manager to obtain information necessary for 
transmission of isochronous data, and setting 
the obtained information into said identified 
node to establish a connection which supports 
saldtransnftission. 

A metiiod for establishing a connection between 
ones of a plurality nodes attached to an IEEE-1394 
serial bus. each of said nodes including a configu- 
ration ROM and identified tyy a node identifier, com- 
prising tiiester^of: 

a) reading infbnnation from the configuration 
ROM of each of said nodes and mapping the 
identifier of the node to the read infbmurtion in 
a mapping table; 

b) identifying a node having required node 
capabilities according to information stored in 
said mapping table; 

c) requesting an isochronous resource man- 
ager to obtain infomtation necessary for trans- 
mission of isochronous data; and 

d) establishing a connection to said dentified 
node according to the obt^ned information. 

The metiiod of daim 3. wherein the step (a) com- 
prtees the steps of: 

reading a data quadlet from the configuration 
ROM of each node; and 
reading a data tHock from a location of the con- 
figuration ROM of tiie node which is specified 
by said data quadlet and mapping the data 
block to tiie node identifier of tiie node in said 
mapping tabia 
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ITte metiml of claim 3. wherein the st^ (a) com- 
prise the steps of: 

transmitting a read data quadlet (RDQ) unicast 
request packet to the serial bus indicating a 
stc»rage bcation of a data quadlet and receiving 
a (RDQ) response packet from each of said 
nodes indicating tiie data length of a data tkxk 
following said data quadlet; and 
transmitting a read data block (RDB) unkast 
request packet to tiie serial bus indicating said 
data length and a storage location of said data 
block and receiving a RDB response packet 
from each node so that said data blod< is 
obtained from tiie configuration ROM of the 
node and mapping the obtained data block to 
the node identifier of the node in said mapping 
table. 

The method of daim 3, wherein said klentif ied node 
indudes a plug control register, wherein st^ (b) 
comprises: 

reading data from the mapping cable to identify 
ones of said nodes having required node capa- 
bilities: 

requesting an isochronous resource manager 
to obtain infomnation necessary for transmis- 
sion of isochronous data; 
setting the obtained information into tite plug 
control register of said kJentified node; and 
establishing a connection according to the 
information set in said plug control register. 
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